Network-performance statistics using end-node computer systems

ABSTRACT

A method for quantifying communication performance in a communication network comprising computer systems communicatively coupled to each other with communication equipment. In one embodiment, the present invention measures performance statistics associated with data packets sent and received by the computer systems. First, this embodiment applies a first time-stamp to data packets sent by a computer system over the communication equipment, and applies a second time-stamp to data packets received by the computer system over the communication equipment. Second, in this embodiment the present invention correlates a first data packet sent by a first computer system over the communication network to a second data packet sent by a second computer system over the communication network. Third, in this embodiment the present invention computes a difference between a first time-stamp of the first data packet and a second time-stamp of the second data packet. Next, this embodiment calculates performance statistics measured on the difference and stores the performance statistics in a memory unit within the first computer system. Finally, in this embodiment the first computer system reports the stored performance statistics to a central computer system.

TECHNICAL FIELD

The present invention relates to the field of computer systemcommunication networks. In particular, the present invention pertains tonetwork monitoring and management.

BACKGROUND ART

Computer systems linked to each other in a communication network arecommonly used in businesses and like organizations. Computer systemcommunication networks (“networks”) are growing in size—as measured bythe number of applications and the number of users they support—due toimprovements in network reliability and the recognition of associatedbenefits such as increased productivity.

As the size of networks increases and as organizations become morereliant on such networks, the importance of effective network managementtools also grows. In response to the need for standardization of suchtools, primarily to control costs but also because components in anetwork are likely to originate from many different vendors, the SimpleNetwork Management Protocol (SNMP) was developed and widely adopted. Anumber of management information bases (MIBs) have been defined sinceadoption of SNMP, such as MIB-II, Remote Network Monitoring (RMON) andlater RMON2. RMON and RMON2 provide the capability for remote networkmonitoring; that is, a network manager is able to monitor networkperformance from a central computer system that has access to othercomponents on the network, referred to as RMON probes, that monitorlocal areas of the network.

SNMP, RMON and RMON2 thus are network management software tools thatprovide a set of standards for network management and control, includinga standard protocol, a specification for database structure, and a setof data objects. RMON and RMON2 are implemented in a network throughmanagement information bases (MIBs) which contain instructionsspecifying the data that are to be collected, how the data are to beidentified, and other information pertinent to the purpose of networkmonitoring. The MIBs are implemented through the RMON probes to monitorthe local areas of the network.

Network managers use the RMON and RMON2 MIBs using SNMP to collectinformation regarding the performance of the network. By collectinginformation about network performance and analyzing it, the networkmanager is able to recognize situations indicating that either a problemis present or impending.

For example, the network manager (or any of the network users, for thatmatter) may be interested in obtaining performance statistics such asthe average and worst-case performance times and the reliability of thenetwork for a particular application. Such applications generallydescribe a transaction between a user that is accessing the networkthrough a client computer system and a server computer system thatresponds to the client computer system with the requested information.Network. managers need performance statistics to help them manage andmaintain the network and to plan for network improvements. For example,performance statistics can be used to recognize bottlenecks in thenetwork before they cause problems so that corrective action can betaken. If the performance statistics indicate a growing load in one areaof the network, network traffic (in the form of data packets that travelthrough the network's communication equipment) can be routed along adifferent path. Statistics accumulated over a longer period of time canbe used to help decide inwhether it is necessary to expand particularareas of the network.

Performance statistics are also necessary for businesses and the like todetermine whether the network support provided by a vendor of networkmanagement services is satisfactory or not. Many businesses contractwith vendors for network management services. Such contracts aretypically implemented with service level agreements (SLAs) which specifymetrics against which the provider of the network management services ismeasured. These metrics are used to quantify standards of performancethat allow businesses to assess not only the performance of the networkbut also the performance of the network management services provider.SLAs generally include a provision specifying metrics for performancetime for critical applications, where performance time, for example, isconsidered to be the amount of time between the time a user submits arequest via the network and the time until the response to that requestis received by the user. An effective network management tool shouldtherefore provide a means for monitoring the network and gatheringperformance statistics for comparison against the requirements containedin the SLAs. However, as will be seen in the discussion below, thenetwork management tools in the prior art do not provide a ready meansof demonstrating compliance with SLAs.

Prior art network management tools have trouble aiding the networkmanager in determining whether a problem within the network isassociated with the network or with the system hardware supporting thenetwork, so that the network manager can identify and implement theappropriate corrective action. For example, if a user places a requestfor a particular application to a server computer and a response is notreceived, the prior art network management tools do not. generallyidentify whether the problem is occurring because of a bottleneck in thenetwork or because the server is not functioning. Therefore, as will beseen in the discussion to follow, the network management tools in theprior art do not provide a ready means of monitoring performance of theentire network so that problems can be quickly detected.

With reference to FIG. 1, a prior art method used for network monitoringis illustrated for a simplified network 100. Network 100 is typicallycomprised of a plurality of client computer systems 110 a, 110 b and 110c networked with a number of different servers 130 a, 130 b and 130 c.For this discussion, the focus is on client computer system 110 cconnected via communication lines 120 and 122 to server computer system130 c. Data packets (not shown) from client computer system 110 c travelto server computer system 130 c and back on either of communicationlines 120 and 122, depending on the amount of traffic present on thoselines due to simultaneous communications between client computer systems110 a and 110 b and server computer systems 130 a, 130 b and 130 c. Therequest data packets issued from client computer system 110 c containdata that specify the address of client computer system 110 c and theaddress of destination server computer system 130 c, as well as otherdata pertinent to the application being used, such as data defining therequest being made. The response data packets issued from servercomputer system 130 c also contain the sender and destination address aswell as other data needed to respond to the request.

With reference still to FIG. 1, coupled into communication lines 120 and122 are other communications equipment such as switches 124 and 125 androuters 126 and 127. Also on communication lines 120 and 122 are RMONprobes 140 and 142 (the term “RMON” refers to both RMON and RMON2). AnRMON probe typically operates in a promiscuous mode, observing everydata packet that passes only through the communication line to which itis coupled.

RMON MIBs provide the capability to define filters that can be used tolimit the number of data packets observed by an RMON probe that are tobe captured or counted. Filters are specified based on the type of datapacket or other packet characteristics associated with the datacontained within the data packet. Filters permit the RMON probe toscreen observed data packets on the basis of recognition characteristicsspecified by the filter. Data packets are captured or counted by theRMON probe on the basis of a match (or a failure to match) with thespecified recognition characteristics. Filters can be combined usinglogical “and” and “or” operations to define a more complex filter to beapplied to data packets, thus focusing the screen onto a narrower groupof data packets. Data packets that pass through the complex filter areselected for capture or counting and are referred to as a channel.

Packet monitoring using probes (as shown in FIG. 1) is problematic whendata switching is used in network 100. Assume a user issues a requestdata packet (not shown) from client computer system 110 c that is routedthrough communications line 120 to server computer system 130 c. RMONprobe 140 observes the request data packet and in this case, because ofthe filter specified, captures and counts the data packet. Servercomputer system 130 c responds to the request data packet and transmitsa response data packet (not shown). However, because of increasedtraffic on communications line 120, the response data packet is moreefficiently routed back to client computer system 110 c throughcommunications line 122 and is observed by RMON probe 142. Because ofthe filter specified, RMON probe 142 also captures and counts the datapacket.

In the prior art the RMON probes are only capable of making a count ofthe number of filtered data packets, which provides only a limitedmeasure of the performance of the network. Thus, one drawback to theprior art is that, because of the nature of switched networks, a datapacket may take one route from a client computer system to a servercomputer system and a different route back. Therefore, the packets arenever correlated because they are counted by two different probes andeach probe operates independently.

For example, the network manager would expect that the number offiltered response data packets and filtered request data packets wouldbe equal, and if not, this would provide an indication of a potentialproblem on the network. However, this information only indicates thereliability of the network for carrying data packets, or the reliabilityof a server computer system to respond to a request, but does notprovide a measure of the time it took to respond to the request.Therefore, another drawback to the prior art is that it does not measureperformance times such as application response time, applicationprocessing time, or network latency, because packets might not becorrelated if they are captured by different probes. Thus, in the priorart the network manager or a user does not have the desired informationregarding the average and worst-case performance times. Hence, anotherdrawback to the prior art is that the network services provider cannotreadily demonstrate compliance to the governing SLA.

With reference again to FIG. 1, it is possible that, after the responsedata packet passes RMON probe 142 and is counted by RMON probe 142, afault on communications line 122 may occur so that the response datapacket is not delivered to client computer system 110 c. For example, afailure of switch 125 may occur so that the response data packet is notable to complete its journey. However, in the prior art the responsedata packet may still be counted as a successful transaction. Thus, adisadvantage to the prior art is that a fault in the network may not bedetected by the network monitoring software, and would only beeventually noticed by the user who did not receive a response to his/herrequest. Another drawback to the prior art is therefore that a fault inthe network may not be noticed in a timely manner. An additionaldrawback to the prior art is that the accuracy of the performancestatistics may be affected by the location of the RMON probes.

One prior art system attempts to address some of the disadvantagesidentified above by incorporating RMON into routers or switches insteadof a probe, and adding a plurality of these components to the network.However, a disadvantage to this prior art system is that the speed atwhich the component (e.g., a switch) performs its primary function issignificantly slowed by the addition of the network monitoring function,because of the complexity of RMON MIBs and the application of multiplefilters. In addition, another drawback to this prior art system is thatthe cost of the component such as a switch is substantially increased bythe incorporation of the RMON facilities. This prior art system alsodoes not address the other disadvantages identified above, such as theinability to measure performance times and demonstrate compliance withSLAs in a switched communication system.

Accordingly, a need exists for a method to monitor a computer systemcommunication network that readily and quickly detects and identifies adegradation of the network. A need further exists for a method thataccomplishes the above and enables the network manager to demonstratecompliance with the provisions of the governing SLA. A need yet existsfor a method that accomplishes the above and also provides an accuratemeasure of the network performance as well as its reliability. Finally,a need exists for a method that accomplishes the above and iscost-effective and compatible with the SNMP protocol that is currentlyemployed. The present invention solves these needs. These and otherobjects and advantages of the present invention will become obvious tothose of ordinary skill in the art after having read the followingdetailed description of the preferred embodiments which are illustratedin the various drawing figures.

DISCLOSURE OF THE INVENTION

The present invention provides a method to monitor a computer systemcommunication network that readily and quickly detects and identifies adegradation of the network. The present invention also provides a methodthat accomplishes the above and enables the network manager todemonstrate compliance with the provisions of the governing servicelevel agreement (SLA). The present invention further provides a methodthat accomplishes the above and also provides an accurate measure of thenetwork performance as well as its reliability. Finally, the presentinvention provides a method that accomplishes the above and iscost-effective and compatible with the Simple Network ManagementProtocol that is currently employed in many communication networks.

The present invention described herein provides a method for quantifyingcommunication performance in a communication network having computersystems communicatively coupled to each other with communicationequipment. Specifically, in one embodiment, the present invention isimplemented on a client computer system and measures performancestatistics associated with data packets sent and received by thecomputer systems. First, this embodiment applies a first time-stamp todata packets sent by a computer system over the communication equipment,and applies a second time-stamp to data packets received by the computersystem over the communication equipment. Second, in this embodiment, thepresent invention correlates a first data packet sent by a firstcomputer system over the communication network to a second data packetsent by a second computer system over the communication network. Third,in this embodiment, the present invention computes a difference betweena time-stamp of the first data packet and a time-stamp of the seconddata packet. Next, this embodiment calculates performance statisticsmeasured on the difference and stores the performance statistics in amemory unit within the first computer system. Finally, in thisembodiment the first computer system reports the stored performancestatistics to a central computer system.

In one embodiment, the present invention implements the method describedabove using a management information base extension to Remote NetworkMonitoring (RMON)-based computer software, in which the managementinformation base extension is comprised of a response time controltable, a response time correlation table, a response time data table,and a response time statistics database.

In one embodiment, the present invention provides the method describedabove and applies the time-stamp at the network interface cards of thecomputer systems. In another embodiment, the present invention providesthe method described above and applies the time-stamp at the protocolstack of the computer systems.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and form a part ofthis specification, illustrate embodiments of the invention and,together with the-description, serve to explain the principles of theinvention:

FIG. 1 is a block diagram of a computer system communication network inaccordance with the prior art.

FIG. 2 shows a general purpose computer system upon which embodiments ofthe present invention may be practiced.

FIG. 3 is a diagram of an exemplary computer system communicationnetwork upon which the present invention may be practiced.

FIG. 4 is a diagram defining performance statistics for an exemplarycomputer system communication network upon which the present inventionmay be practiced.

FIG. 5 is a diagram illustrating an arrangement of memory units in acomputer system in accordance with one embodiment of the presentinvention.

FIG. 6 is an illustration of a performance statistics data table inaccordance with one embodiment of the present invention.

FIG. 7 is a flowchart of a process for defining a control table inaccordance with one embodiment of the present invention.

FIG. 8 is a flowchart of a process for compiling performance statisticsin accordance with one embodiment of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

Reference will now be made in detail to the preferred embodiments of theinvention, examples of which are illustrated in the accompanyingdrawings. While the invention is described in conjunction with thepreferred embodiments, it is understood that they are not intended tolimit the invention to these embodiments. On the contrary, the inventionis intended to cover alternatives, modifications and equivalents, whichmay be included within the spirit and scope of the invention as definedby the appended claims. Furthermore, in the following detaileddescription of the present invention, numerous specific details are setforth in order to provide a thorough understanding of the presentinvention. However, it will be obvious to one of ordinary skill in theart that the present invention may be practiced without these. specificdetails. In other instances, well-known methods, procedures, components,and circuits have not been described in detail so as not tounnecessarily obscure aspects of the present invention.

Some portions of the detailed descriptions which follow are presented interms of procedures, logic blocks, processing, and other symbolicrepresentations of operations on data bits within a computer memory.These descriptions and representations are the means used by thoseskilled in the data processing arts to most effectively convey thesubstance of their work to others skilled in the art. A procedure, logicblock, process, etc., is here, and generally, conceived to be aself-consistent sequence of steps or instructions leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated in a computersystem. It has proven convenient at times, principally for reasons ofcommon usage, to refer to these signals as bits, bytes, values,elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the followingdiscussions, it is appreciated that throughout the present invention,discussions utilizing terms such as “processing” or “computing” or“calculating” or “determining” or “displaying” or the like, refer to theaction and processes of a computer system (e.g., processes of FIGS. 7and 8), or similar electronic computing device, that manipulates andtransforms data represented as physical (electronic) quantities withinthe computer system's registers and memories into other data similarlyrepresented as physical quantities within the computer system memoriesor registers or other such information storage, transmission or displaydevices.

Refer to FIG. 2 which illustrates client computer system 300 (thefollowing discussion is also pertinent to a server computer system). Ingeneral, client computer system 300 used by the embodiments of thepresent invention comprises a bus 200 for communicating information, acentral processor 201 coupled with bus 200 for processing informationand instructions, a random access memory 202 coupled with bus 200 forstoring information and instructions for central processor 201, aread-only memory 203 coupled with bus 200 for storing static informationand instructions for central processor 201, a data storage device 204such as a magnetic or optical disk and disk drive coupled with bus 200for storing information and instructions, a display device 205 coupledto bus 200 for displaying information to the computer user, an optionalalphanumeric input device 206 including alphanumeric and function keyscoupled to bus 200 for communicating information and command selectionsto central processor 201, an optional cursor control device 207 coupledto bus 200 for communicating user input information and commandselections to central processor 201, and a network interface card (NIC)208 coupled to bus 200 for communicating from a communication network tocentral processor 201.

Display device 205 of FIG. 2 utilized with client computer system 300 ofthe present invention may be a liquid crystal device, cathode ray tube,or other display device suitable for creating graphic images andalphanumeric characters recognizable to the user. Cursor control device207 allows the computer user to dynamically signal the two-dimensionalmovement of a visible symbol (pointer) on a display screen of displaydevice 205. Many implementations of the cursor control device are knownin the art including a trackball, mouse, joystick or special keys onalphanumeric input device 206 capable of signaling movement of a givendirection or manner of displacement. It is to be appreciated that thecursor means 207 also may be directed and/or activated via input fromthe keyboard using special keys and key sequence commands.Alternatively, the cursor may be directed and/or activated via inputfrom a number of specially adapted cursor directing devices.

With reference now to FIG. 3, a diagram showing client computer system300 coupled to server computer system 350 in communication network 305is provided. In a typical communication network, there are a pluralityof client computer systems and server computer systems coupled to eachother with communications equipment. For the discussion herein, a singleclient computer system 300 is shown coupled via communications lines 340and 342 with a single server computer system 350, but more computersystems could be employed. Client computer system 300 and servercomputer system 350 are each connected in communication network 305 byphysical layer network interface cards (NICs) 330 and 380, respectively.

With reference still to FIG. 3, the software executed by centralprocessor 201 (FIG. 2) of client computer system 300 is represented byapplication layer 310 which is separated from the remainder of protocolstack 320. Application layer 310 defines the manner in which applicationprograms interact with the communication network, where applicationsinclude computer software programs, word processors, database managementsystems, electronic mail, and the like. Protocol stack 320 contains theremaining layers of software that define the computer-to-computer orcomputer-to-network protocol, where protocol defines the procedures tobe followed when data are transmitted and received. In a similar manner,server computer system 350 includes analogous application-layer 360 andprotocol stack 370.

With reference to FIG. 3, one of the software layers (e.g., applicationlayer 310) of client computer system 300 transmits a request to servercomputer system 350 in the form of request data packet 390, and servercomputer system 350 responds to the request in the form of response datapacket 395. In this example, request data packet 390 and response datapacket 395 are shown traveling by different communications lines (e.g.,in a switched network environment), but it is appreciated that in thepresent invention the data packets alternatively can travel over thesame communications line.

The present invention is a client-implemented process that determinesperformance statistics associated with the request and response datapackets sent and received by the client and server computer systems. Thepresent invention uses filters to identify and select request andresponse data packets that will be used to generate performancestatistics. The present invention applies time-stamps to the identifiedrequest and response data packets. The present invention usescorrelation rules to correlate a response packet to a request packet, sothat the time-stamps can be used to determine time intervals associatedwith the time between transmission and reception of the data packets, bythe computer systems. The present invention uses the time intervals todetermine the performance statistics. In one embodiment, the presentinvention implements the above method in the form of extensions to aRemote Network Monitoring (RMON) management information base (MIB).

NETWORK PERFORMANCE STATISTICS—DEFINITIONS

With reference now to FIG. 4, client computer system 300 is coupled toserver computer system 350 in communication network 305. A data packettakes a measurable amount of time to travel from client computer system300 to server computer system 350, and vice versa. It also takes ameasurable amount of time for a computer system to perform anapplication.

Continuing with reference to FIG. 4, the amount of time for a data.packet to travel from one computer system to another is referred to as“latency.” “Network latency” is the amount of time required for the datapacket to travel from point A, A′ at which it exits one computer systemto point B, B′ at which it enters another computer system. Withreference back to FIG. 3, network latency is the time to travel one-wayfrom network interface card 330 in client computer system 300 to networkinterface card 380 in server computer system 350 and vice versa. Thenetwork latency from client computer system 300 to server computersystem 350 is determined by computing the difference between time-stampsT2 and T1, and the network latency from server computer system 350 toclient computer system 300 is determined by computing the timedifference between time-stamps T6 and T5.

With reference to FIGS. 3 and 4, “application processing time” is thetime required for server computer system 350 to complete performing anapplication in response to a request received from client computersystem 300. Application processing time is the elapsed time between thetime when request data packet 390 enters server computer system 350 andthe time when the correlated response data packet 395 exits servercomputer system 350 (one-way from point D to point E). The applicationprocessing time is determined for correlated data packets by computingthe difference between time-stamps T5 and T2.

With reference to FIGS. 3 and 4, “application response time” is theelapsed time between the time when request data packet 390 exits clientcomputer system 300 and the time when response data packet 395 entersclient computer system 300 (round trip from point A to point C), whereresponse data packet 395 is sent in response to request data packet 390.Thus, application response time includes network latency from clientcomputer system 300 to server computer system 350, applicationprocessing time in server computer system 350, and network latency fromserver computer system 350 to client computer system 300. Theapplication response time is determined for correlated data packets bycomputing the difference between time-stamps T6 and T1.

NETWORK PERFORMANCE STATISTICS—OPERATION

Refer now to FIG. 5, which illustrates the memory structure of thepresent embodiment of the present invention within the computer-readablememory units of client computer system 300 and also in server computersystem 350 of FIG. 3. In the present embodiment, filters 505 a, 505 band 505 c contain recognition characteristics for recognizing andselecting request data packets 390 that are of interest to the networkmanager (that is, the data packets that will be used to generateperformance statistics). Similarly, filters 506 a, 506 b and 506 ccontain recognition characteristics for recognizing and selectingresponse data packets 395 that are of interest to the network manager.It is appreciated that for the discussion herein two sets of threefilters each are shown; however, the number of filters applied in thepresent invention may be different from the number shown.

Continuing with reference to FIG. 5, request channel 520 stores requestpackets 390 selected by filters 505 a-c. Similarly, response channel 521stores response packets 395 selected by filters 506 a-c. In the presentembodiment, each filter 505 a-c and 506 a-c is uniquely indexed, andthus request channel 520 and response channel 521 each specify thefilters to be applied to request and response data packets 390 and 395,respectively, by referencing the appropriate index. In a similar manner,in the present embodiment request channel 520 and response channel 521are each uniquely indexed so that they can be referenced and acted on inaccordance with the present invention.

With reference still to FIG. 5, in the present embodiment, correlationrules 525 a, 525 b and 525 c to be applied to request channel 520 andresponse channel 521 are specified in correlation table 526. Althoughthree correlation rules are shown in FIG. 5, it is appreciated that adifferent number of correlation rules may be applied in accordance withthe present invention. In the present embodiment, each correlation rule525 a-c is uniquely indexed, and thus correlation table 526 specifiesthe correlation rules to be applied by reference to the appropriateindex. In the present embodiment, correlation table 526 is identified bya unique index that associates the correlation table with control table510.

Continuing with reference to FIG. 5, in the present embodiment, controltable 510 references request channel 520 and response channel 521 usingtheir unique indices. The present invention applies correlation rules525 a-c to request channel 520 and to response channel 521 to identify amatch of a response data packet 395 to a request data packet 390,thereby forming a correlated request and response data packet 530. Inthe present embodiment, each request data packet 390 and response datapacket 395 includes time-stamps corresponding to the time when it wastransmitted and received by a computer system. For each correlated datapacket 530, in the present embodiment, data table 540 is used to storeentries consisting of the time difference between these time-stamps. Inthis embodiment, statistics table 550 is used to store performancestatistics that are based on the information stored in data table 540.At a time interval specified by the network manager, the performancestatistics in statistics table 550 are read to user-history table 560.In this embodiment, control table 510, correlation table 526, data table540 and statistics table 550 are linked to each other through the use ofan index common to each.

Refer now to FIG. 6 which shows statistics table 550. In the presentembodiment, statistics table 550 accumulates the minimum, maximum,average and median for the entries stored in data table 540. Theinformation stored in statistics table 550 is collected for a specifiedtime interval, and then read to user-history table 560. In user-historytable 560, data are stored for each of a plurality of time intervals.The data stored for each time interval may also be combined to computedata for a larger time interval.

FIG. 7 illustrates a process 700 for creating and activating a controltable, where process 700 is implemented as program instructions storedin computer-readable memory units of client computer system 300 (FIG. 3)and executed by central processor 201 (FIG. 2), and also stored andexecuted on server computer system 350 (FIG. 3). In the presentembodiment of the present invention, a set of filters, channels, andcorresponding correlation rules for application to data packets arepredefined and stored in the computer system. In another embodiment, instep 710 a filter or combination of filters is defined and created bythe network manager for application to request data packets. Similarly,in step 720, a filter or combination of filters is defined and createdfor application to response data packets. Filters screen the datapackets by comparing the bit/byte pattern of the data in certain definedfields of the data packets to the recognition characteristics specifiedby the filter definition. Filters are combined by the network managerusing logical operations such as “and” and “or” to define more complexfilters for screening data packets traveling over the communicationnetwork. Data packets are selected on the basis of a match (oralternatively, a failure to match) with the recognition characteristicsof the filter or the combination of filters. Data packets that areidentified and selected by the filter or combination of filters form a.channel. Thus, a channel accepts data packets that share recognitioncharacteristics that are of interest to the network manager.

With reference still to steps 710 and 720 of FIG. 7, in the presentembodiment of the present invention, the network manager uses an RMONMIB to specify a filter or a combination of filters (e.g., filters 505a-c of FIG. 5) to identify and capture request data packets. (The term“RMON” is used to mean both RMON and RMON2.) The request channel (e.g.,request channel 520 of FIG. 5) contains request data packets thatsatisfy the filter(s) when the control table is activated by the networkmanager. Similarly, in the present embodiment of the present inventionthe network manager uses an RMON MIB to specify a filter or combinationof filters (e.g., filters 506 a-c of FIG. 5) to identify and captureresponse data packets. The response channel (e.g., response channel 521of FIG. 5) contains response data packets that satisfy the filter(s). Inthe present embodiment, the filters are applied at the end-node computersystems. That is, in the present embodiment a filter is applied ateither or both the client computer system and the server computersystem, depending on the type of performance statistics that are beingcollected.

Depending on the type of information sought by the network managerregarding the performance of the communication network, the networkmanager may create more than one response channel and more than onerequest channel. Each response channel and request channel is indexed,and the index is used in the control table by the network manager tospecify which response channel and which request channel are to be usedas the basis for generating performance statistics.

With reference now to step 730 of FIG. 7, in one embodiment of thepresent invention, correlation rules (e.g., correlation rules 525 ofFIG. 5) are specified based on the knowledge of protocol sessionbehavior. For example, in a Transmission Control Protocol (TCP) session,one correlation matches the source Internet Protocol (IP) address in therequest channel to the destination IP address in the response channel.

With reference back to FIG. 3, the central processors of client computersystem 300 and server computer system 350 each incorporate anapplication layer and a protocol stack (note: in the InternationalStandards Organization/Open System Interconnection [ISO/OSI] model, the,application layer is the top layer of the protocol stack, but forsimplicity herein the application layer is separately identified fromthe remainder of the protocol stack). A user of client computer system300 issues an application request in the form of request data packet 390from application layer 310. Request data packet 390 thus initiallycontains data that identify the type of application being utilized orrequested. As request data packet 390 passes through each layer ofprotocol stack 320, each layer adds bits and. bytes of information torequest data packet 390 in a logical and standard format established bythe ISO/OSI model. Therefore, when request data packet 390 exits thebottom of protocol stack 320, it contains a set of data (includingsource and destination addresses) that is logically organized andformatted in data fields according to a known standard. In a mannersimilar to the above, response data packet 395 also contains a set ofdata logically organized and formatted in data fields according to thesame known standard.

By way of illustrating the above, each request and response data packetcontains a destination address and a source address that are locatedwithin a specific field in each data packet. A correlation rule isdefined to compare the destination and source addresses within requestand response data packets as one method of establishing a correlationbetween request and response data packets. Other correlation rules aredefined to compare other aspects of the request and response datapackets until the correlation is complete, and the response data packetis matched to the request data packet that prompted the response.

With reference again to FIG. 3, client computer system 300 transmitsnumerous request data packets 390 to server computer system 350 and viceversa, and therefore the correlation rules defined in the presentembodiment include a sophisticated set of recognition characteristics.The present invention defines correlation rules 525 (FIG. 5) that are ofsufficient sophistication that a specific response data packet can beidentified and matched with the specific request data packet to whichthe response data packet is responding. Correlation rules 525 that areto be applied to the request and response data packets of interest aredefined in a correlation table (e.g., correlation table 526 of FIG. 5).

As discussed above, the present embodiment of the present inventionincorporates correlation rules 525 to identify applications in datapackets that are based on a known standard. The present embodiment alsoallows for correlation rules 525 to recognize and correlate data packetscontaining applications that potentially contain a protocol notgenerally used. For example, a business may use a unique applicationdeveloped by that business and utilized solely on its internalcommunication network. The present embodiment incorporates correlationrules that can be designed to specifically identify those uniqueapplications.

With reference back to FIG. 7, in step 740 of the present embodiment thenetwork manager specifies a control table (e.g., control table 510 ofFIG. 5). In the present embodiment, control table 510 is used by thenetwork manager to specify the request and response channels and thecorrelation rules that will be used to collect performance statistics.In step 750 of the present embodiment, control table 510 is used by thenetwork manager to specify the time interval over which the performancestatistics are to be collected. In step 760, once control table 510 iscomplete, the network manager activates control table 510 to collect thedesired performance statistics in accordance with the present invention.

FIG. 8 provides details of step 760 (FIG. 7) that are implemented asprogram instructions stored in computer-readable memory units of clientcomputer system 300 (FIG. 3) and executed by central processor 201 (FIG.2), and also stored and executed on server computer system 350 (FIG. 3).In the present embodiment of the present invention, in steps 861 and 862the filter or combination of filters is applied in order to select datapackets sent by one or the other of the computer systems. In the presentembodiment, with reference also to FIG. 3, in step 861 the filter(s) areapplied to data packets transmitted by client. computer system 300. Instep 862, in the present embodiment, the filter(s) are applied to datapackets transmitted by server computer system 350. Thus, a filter isapplied to each of the data packets, and the request data packets thatsatisfy the filter(s) are collected in a request channel, and theresponse data packets that satisfy the filter(s) are placed in aresponse channel. The accepted data packets will be used as the basisfor generating performance statistics. In the present embodiment, thefilters are applied at the end-node computer systems. That is, in thepresent embodiment a filter is applied at either or both the clientcomputer system and the server computer system, depending on the type ofperformance statistics that are being collected.

With reference again to steps 861 and 862 of FIG. 8, in the presentembodiment time-stamps are applied to the request and response datapackets at the end-node computer systems; that is, time-stamps areapplied at client computer system 300 and at server computer system 350.In step 861, request data packet 390 receives a time-stamp from clientcomputer system 300 when it exits the client computer system, and atime-stamp from server computer system 350 when it enters the servercomputer system. In step 862, response data packet 395 receives atime-stamp from server computer system 350 when it exits the servercomputer system, and a time-stamp from client computer system 300 whenit enters the client computer system. Thus, by using the end-nodecomputer systems in the present invention, the time-stamps provide anaccurate measure of when the data packets are transmitted and receivedby each of the computer systems in the computer network. With referencealso to FIG. 3, in one embodiment the time-stamps are applied at thebottom of the protocol stacks of client computer system 300 and servercomputer system 350 (protocol stacks 320 and 370). In anotherembodiment, the time-stamps are applied at the network interface cards(NICs) of client computer system 300 and server computer system 350(NICs 330 and 380).

With reference now to step 863 of FIG. 8, and also with reference toFIG. 3, the present embodiment of the present invention correlatesresponse data packet 395 from server computer system 350 to request datapacket 390 from client computer system 300; that is, the two datapackets are identified, matched, and paired. In the present embodiment,request and response data packets 390 and 395 are correlated using a setof correlation rules 525 (FIG. 5) specified and applied to the requestand response channels. In the present embodiment, the set of correlationrules to be applied are specified in control table 510 (FIG. 5) thatalso references the pertinent response and request channels. A requestdata packet 390 and response data packet 395 that each satisfy the sameset of correlation rules are thus uniquely identified as matching (thatis, a response data packet 395 is identified as the response to arequest data packet 390 that requested the response) and are paired toform a correlated data packet 530 (FIG. 5).

With reference now to step 864 of FIG. 8, the present embodimentdetermines performance time based on the time-stamps of each pair ofcorrelated data packets (e.g., correlated data packet 530 of FIG. 5).The present embodiment computes the time difference between thetime-stamps that were applied to the request data packet that comprisesone part of the correlated data packet and the time-stamps that wereapplied to the response data packet that comprises the other part of thecorrelated data packet. In one embodiment, with reference also to FIG.3, the present invention computes the application response time usingthe time-stamps of each correlated data packet 530, by computing thedifference between the time request data packet 390 was transmitted byclient computer system 300 and the time that correlated response datapacket 395 was received by client computer system 300. In oneembodiment, the present invention computes the application processingtime using the time-stamps of each correlated data packet 530, bycomputing the difference between the time request data packet 390 wasreceived by server computer system 350 and the time correlated responsedata packet 395 was transmitted by server computer system 350. In oneembodiment, the present invention calculates the network latency usingthe time-stamps applied to each data packet when it is sent by onecomputer system and received by the other computer system, by computingthe difference between the time request data packet 390 was transmittedby client computer system 300 and received by server computer system350, and by computing the difference between the time correlatedresponse data packet 395 was transmitted by server computer system 350and received by client computer system 300. As previously describedabove, the time-stamps provide an accurate measure of when the datapackets are transmitted and received by the computer systems on thecommunication network. Thus, the use of the time-stamps to determineapplication response time, application processing time, and networklatency provide an accurate measure of network performance andreliability.

With reference still to step 864 of FIG. 8, the present embodiment ofthe present invention calculates performance statistics based on theapplication response time, application processing time, and networklatency for a plurality of correlated data packets 530 of FIG. 5, wherethe correlated data packets have each satisfied the correlation rulesand hence represent transactions on the communication network ofinterest to the network manager for monitoring purposes. For example,correlated data packets that all pertain to a particular application maybe used as the basis for calculating performance statistics associatedwith that application. The performance statistics include statisticssuch as the mean, median, minimum and maximum response times for aparticular control table 510 (FIG. 5). In the present embodiment theperformance statistics are automatically calculated and accumulated fora programmable interval of time specified by the network manager, e.g.,for 30-minute intervals of time, although it is appreciated that otherunits of time can be specified in accordance with the present invention.The present embodiment then stores the performance statistics in amemory unit within a computer system that is on the communicationnetwork. In one embodiment, the performance statistics associated with aclient computer system are stored in a memory unit within that clientcomputer system.

With reference now to step 865 of FIG. 8, in the present embodiment theperformance statistics for each consecutive 30-minute interval are thenautomatically used to calculate performance statistics for aprogrammable interval of time, e.g., for a 6-hour interval, by combiningthe performance statistics for each 30-minute interval. The performancestatistics for each such interval are automatically used to determineperformance statistics for a longer interval of time, e.g., for a24-hour interval, by combining the performance statistics for each6-hour interval. In this manner, the performance statistics are readilyavailable to the network manager for either a shorter or a longer timeinterval. It is appreciated that other intervals of time can bespecified in accordance with the present invention. Thus, the presentembodiment of the present invention provides a method for readily andquickly detecting and identifying degradation of the network. Theperformance statistics also provide the information needed to enable thenetwork manager to compare network performance against the metricsspecified in the service level agreement. The performance statisticsalso permit the network manager to perform active trouble-shooting todetermine the source of any network degradation in addition to themonitoring function.

With reference now to step 866 of FIG. 8, in the present embodiment theperformance statistics are reported to a central computer system. In oneembodiment, the performance statistics are periodically andautomatically reported to the central computer system from each clientcomputer system on the communication network at a programmable intervalof time, e.g., every 30 minutes, although it is appreciated that otherintervals of time can be specified in accordance with the presentinvention.

With reference now to FIG. 3, it is appreciated that in the presentembodiment, the round-trip network latency may also be readilydetermined using the protocol “heartbeat” data packets that areroutinely generated in protocol stack 320 of client computer system 300and transmitted to protocol stack 370 of server computer system 350, andvice versa. The purpose of such well-known heartbeat data packets is toenable the computer systems to determine that a communication linkexists between the computer systems and to indicate if the link isbroken. The heartbeat data packets do not pass into the applicationlayer of the computer systems. Thus, round-trip network latency can bedetermined by using the time-stamps to time the round trip of theheartbeat data packet, because the time of the round trip does notinclude application processing time. In other words, round-trip networklatency is the difference between time-stamps T6 and T1 when thedifference between time-stamps T4 and T3 is zero.

In the present embodiment, the present invention uses an extension to anRMON MIB to implement the method and perform the steps described abovein order to determine the performance statistics for the communicationnetwork system. As previously discussed, RMON is a supplement to theSNMP protocol currently employed in computer system communicationnetworks, and thus the present embodiment of the present invention iscompatible with the standards currently in use. In the presentembodiment, the RMON MIB extension is comprised of a response timecontrol table, a response time correlation table, a, response time datatable, and a response time statistics database, which are specified indetail in the Code Section below, and which correspond to the method andfunctions of the control table, correlation table, data table, andstatistics table described above for the present embodiment. In thepresent embodiment, the RMON MIB is implemented in the client and servercomputer systems and thus does not require additional hardware. Hence,the present embodiment of the present invention provides acost-effective method for monitoring network performance. The presentembodiment RMON MIB extension is provided in the Code Section below.

Code Section - RMON MIB Extension in Accordance with the PresentInvention Structure of MIB Response Time MIB assumes the availability ofRMONv2 group. This MIB has the following structure. responseTimeresponseTimeCorrelationTable responseTimeCorrelationEntry index of(responseTimeCorrelationControlIndex, responseTimeControlIndex)responseTimeCorrelationControlIndex Integer32,responseTimeCorrelationType Integer32,responseTimeCorrelationMatchMethod Integer32,responseTimeCorrelationMatchByteCode OctetString,responseTimeCorrelationProtcolDirLocalIndex Integer32,responseTimeCorrelationLength Integer32,responseTimeCorrelationRequestOffset Integer32,responseTimeCorrelationResponseOffset Integer32,responseTimeCorrelationOwner DisplayString,responseTimeCorrelationStatus RowStatus responseTimeControlTableresponseTimeControlEntry index of (responseTimeControlIndex)responseTimeControlIndex Integer32,responseTimeControlRequestChannelIndex Integer32,responseTimeControlResponseChanne;Index Integer32,responseTimeControlInterval Integer32, responseTimeControlDataInteger32, responseTimeControlMaxEntries Integer32,responseTimeControlDescr DisplayString, responseTimeControlOwnerOwnerString, responseTimeControlStatus RowStatus responseTimeDataTableresponseTimeDataEntry index of (responseTimeTimeMark,responseTimeControlIndex, responseTimeDataIndex) responseTimeTimeMarkTimeFilter, responseTimeDataIndex Integer32, responseTimeData Integer32responseTimeStats responseTimeStatsEntry index of(responseTimeControlIndex) responseTimeStatsAverage Integer32,responseTimeStatsMedian Integer32, responseTimeStatsMaximum Integer32,responseTimeStatsMinimum Integer32, responseTimeStatsOverallMaximumInteger32 These objects are described in the MIB-Definition.MIB-Definition IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32,Integer32, Gauge32, TimeTicks, Counter64 FROM SNMPv2-SMITEXTUAL-CONVENTION, RowStatus, DisplayString, TimeStamp FROM SNMPv2-TCMODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2, ifIndex FROMRFC1213-MIB rmon, OwnerString, statistics, history, hosts, hostTopN,matrix, etherStatsEntry, etherHistoryEntry, hostEntry, hostTimeEntry,hostTopNEntry, hostTopNControlEntry, matrixSDEntry, matriXDSEntry,filter, channel, channelEntry, capture, captureBufferEntry FROM RMON-MIBresponseTime, responseTimeStatsEntry, nlHost, nlHostEntry, nlMatrix,nlMatrixSDEntry, nlMatriXDSEntry, nlMatrixTopNControlEntry,nlMatrixTopNEntry, alHost, alHostEntry, alMatrix, alMatrixSDEntry,alMatrixTopNControlEntry, alMatrixTopNEntry, alMatriXDSEntry,usrHistory, usrHistoryEntry, rmonConformance, ZeroBasedCounter32 FROMRMON2-MIB; -- { rmon 1 } through { rmon 20 } are defined in RMON [RFC1757] and -- the Token Ring RMON MIB [RFC 1513] and the RMON2 MIB[RFC2021]. -- Object Identifiers private OBJECT IDENTIFIER ::= {internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } a3ComOBJECT IDENTIFIER ::= { enterprises 43 } generic OBJECT IDENTIFIER ::= {a3Com 10 } genExperimental OBJECT IDENTIFIER ::= { generic 1 }a3ComResponseTime OBJECT IDENTIFIER ::= { genExperimental XX } --Response Time Groups responseTime OBJECT IDENTIFIER ::= {a3ComResponseTime 1 } -- -- Response Time Group (responseTime) -- --Collects the response times in milli-seconds for the -- different typeof packets detected on a network segment. -- Control Tables: --responseTimeCorrelationTable -- responseTimeControlTable -- Data Tables:-- responseTimeDataTable -- responseTimeStatsTable --responseTimeCorrelationTable -- This table can be used to correlateip-addresses, sequence numbers, etc. responseTimeCorrelationTableOBJECT-TYPE SYNTAX SEQUENCE OF ResponseTimeCorrelationEntry ACCESSnot-accessible STATUS current DESCRIPTION “A running entry for eachresponseTimeCorrelationIndex is kept in this table after probe createsfirst entry in the responseTimeCorrelationTable.” ::= { responseTime 1 }responseTimeCorrelationEntry OBJECT-TYPE SYNTAXResponseTimeCorrelationEntry ACCESS not-accessible STATUS mandatoryDESCRIPTION “A conceptual row in the responseTimeCorrelationTable. Anexample of the indexing of this entry isresponseTimeCorrelationLength.1.5” INDEX { responseTimeCorrelationIndex,responseTimeCorrelationControlIndex } ::= { responseTimeCorrelationTable1 } ResponseTimeCorrelationEntry ::= SEQUENCE {responseTimeCorrelationIndex Integer32responseTimeCorrelationControlIndex Integer32,responseTimeCorrelationType Integer32,responseTimeCorrelationMatchMethod Integer32,responseTimeCorrelationMatchByteCode OctetString,responseTimeCorrelationProtcolDirLocalIndex Integer32,responseTimeCorrelationLength Integer32,responseTimeCorrelationRequestOffset Integer32,responseTimeCorrelationResponseOffset Integer32,responseTimeCorrelationOwner OctetString, responseTimeCorrelationStatusRowStatus } responseTimeCorrelationIndex OBJECT-TYPE SYNTAX Integer32(1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION “Aunique index for this ResponseTimeCorrelationEntry.” ::= {ResponseTimeCorrelationEntry 1 } responseTimeCorrelationControlIndexOBJECT-TYPE, SYNTAX Integer32 MAX-ACCESS read-create STATUS currentDESCRIPTION “Response Time Control to which this correlation belongs.”::= { ResponseTimeCorrelationEntry 2 } responseTimeCorrelationTypeOBJECT-TYPE, SYNTAX Integer32 MAX-ACCESS read-create STATUS currentDESCRIPTION “Type of correlation. There has to be at least one match foreach type of correlation for the response time.” ::= {ResponseTimeCorrelationEntry 3 } responseTimeCorrelationMatchMethodOBJECT-TYPE, SYNTAX INTEGER { equal(0), byteCode(1), tcpSequence(2) }MAX-ACCESS read-create STATUS current. DESCRIPTION “The method toperform the match between request and response to calculate the responsetime between them. equal(0) matches the ‘length’ bytes in the requestpacket from the request-offset for the protocolDirLocalIndex to the‘length’ bytes in the response packet at the response-offset for theprotocolLocalIndex. So for example, to match source IP address of therequest to the destination IP address in the response,protocolDirLocalIndex will be set to IP, length to 4 bytes and requestoffset to 12 bytes in the IP header for request to response offset of 16in the IP header for response. byteCode(1) useresponseTimeCorrelationByteCode as the Java Virtual Machine (JVM) codeto match the request to response with request and response packets(starting from protocolLocalIndex header) as parameters. JVM may or maynot be supported by the probe. tcpSequence(2) uses the tcp sequencenumbering (based on the length) to match request and response packet.Default is equal(0)” ::= { ResponseTimeCorrelationEntry 4}responseTimeCorrelationByteCode OBJECT-TYPE SYNTAX OctetStringMAX-ACCESS read-create STATUS current DESCRIPTION “Valid only if theresponseTimeControlMatchMethod is ‘byteCode’. This code is to be used asa function and run in the JVM with request and response packet asparameters.” ::= { ResponseTimeCorrelationEntry 5 }responseTimeCorrelationProtcolDirLocalIndex OBJECT-TYPE, SYNTAXInteger32 MAX-ACCESS read-create STATUS current DESCRIPTION “Protocolfrom which to begin correlation.” ::= { ResponseTimeCorrelationEntry 6 }responseTimeCorrelationLength OBJECT-TYPE, SYNTAX Integer32 MAX-ACCESSread-create STATUS current DESCRIPTION “The length of the correlation.”::= { ResponseTimeCorrelationEntry 7 }responseTimeCorrelationRequestOffset OBJECT-TYPE, SYNTAX Integer32MAX-ACCESS read-create STATUS current DESCRIPTION “The offset ofcorrelation in the ‘request’ packet.” ::= { ResponseTimeCorrelationEntry8 } responseTimeCorrelationResponseOffset OBJECT-TYPE, SYNTAX Integer32MAX-ACCESS read-create STATUS current DESCRIPTION “The offset ofcorrelation in the ‘response’ packet.” ::= {ResponseTimeCorrelationEntry 9 } responseTimeCorrelationOwnerOBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS currentDESCRIPTION “The entity that configured this entry and is thereforeusing the resources assigned to it.” ::= { ResponseTimeCorrelationEntry10 } responseTimeCorrelationStatus OBJECT-TYPE SYNTAX RowStatusMAX-ACCESS read-create STATUS current DESCRIPTION “The status of thisrow. An entry may not exist in the active state unless all objects inthe entry have an appropriate value. If this object is not equal toactive(1), this entry shall be deleted.” ::= {ResponseTimeCorrelationEntry 11 } responseTimeControlTable OBJECT-TYPESYNTAX SEQUENCE OF ResponseTimeControlEntry ACCESS not-accessible STATUScurrent DESCRIPTION “Controls the setup of response time table.Rationale: This table controls collection of response time for any userspecified type of packet based on the filters defined through thechannels specified here. This table can be used for network, protocol,application level response time monitoring.” ::= { responseTime 2 }responseTimeControlEntry OBJECT-TYPE SYNTAX ResponseTimeControlEntryACCESS not-accessible STATUS mandatory DESCRIPTION “A conceptual row inthe responseTimeControlTable. An example of the indexing of this entryis responseTimeControlDescr.7” INDEX { responseTimeControlIndex } ::={responseTimeControlTable 1 } ResponseTimeControlEntry ::= SEQUENCE {responseTimeControlIndex Integer32,responseTimeControlRequestChannelIndex Integer32,responseTimeControlResponseChannelIndex Integer32,responseTimeControlInterval Integer32, responseTimeControlDataInteger32, responseTimeControlDescr Integer32,responseTimeControlMaxEntries Integer32, responseTimeControlOwnerOwnerString, responseTimeControlStatus RowStatus }responseTimeControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535)MAX-ACCESS not-accessible STATUS current DESCRIPTION “A unique index forthis responseTimeControlEntry.” ::= { responseTimeControlEntry 1 }responseTimeControlRequestChannelIndex OBJECT-TYPE SYNTAX Integer32MAX-ACCESS read-create STATUS current DESCRIPTION “The Channel Index ofthe request-side of the packet. This Channel Index must already becreated in the channelTable with associated filters. The packet whichget accepted by the channel is considered a response-time ‘request’packet for response time purpose.” ::= { responseTimeControlEntry 2 }responseTimeControlResponseChannelIndex OBJECT-TYPE SYNTAX Integer32MAX-ACCESS read-create STATUS current DESCRIPTION “The Channel Index ofthe response-side of the packet. This Channel Index must already becreated in the channelTable with associated filters. The packet whichget accepted by the channel is considered a response-time ‘response’packet for response time purpose.” ::= { responseTimeControlEntry 3 }responseTimeControlInterval OBJECT-TYPE SYNTAX Integer32 (1..2147483647)MAX-ACCESS read-create STATUS current DESCRIPTION “The interval inseconds over which the data is sampled for the responseTimeStats Table.”DEFVAL { 1800 } ::= { responseTimeControlEntry 6 }responseTimeControlData OBJECT-TYPE, SYNTAX INTEGER { on(1), off(2) }MAX-ACCESS read-create STATUS current DESCRIPTION “This object controlsthe flow of response time data through this control. If this object ison(1), data response-time data is collected. If this object is off(2),response-time data is not collected for this control.” ::= {responseTimeControlEntry 7 } responseTimeControlMaxEntries OBJECT-TYPE,SYNTAX Integer32 (1..65535) MAX-ACCESS read-create STATUS currentDESCRIPTION “The maximum number of entries to maintain in theresponseTimeDataTable. After which older entries are deleted. Defaultmaximum is 1000.” ::= { responseTimeControlEntry 8 }responseTimeControlDescr OBJECT-TYPE SYNTAX DisplayString (SIZE(0..127))MAX-ACCESS read-create STATUS current DESCRIPTION “The description forthe response time being calculated.” ::= { responseTimeControlEntry 9 }responseTimeControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESSread-create STATUS current DESCRIPTION “The entity that configured thisentry and is therefore using the resources assigned to it.” ::= {responseTimeControlEntry 10 } responseTimeControlStatus OBJECT-TYPESYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION “Thestatus of this row. An entry may not exist in the active state unlessall objects in the entry have an appropriate value. If this object isnot equal to active(1), all associated entries in theresponseTimeStatsTable and responseTimeCorrelationTable shall bedeleted.” ::= { responseTimeControlEntry 11 } -- Response Time datatable (responseTimeDataTable) responseTimeDataTable OBJECT-TYPE SYNTAXSEQUENCE OF responseTimeDataEntry ACCESS not-accessible STATUS currentDESCRIPTION “An entry is made in this table when probe finds a ‘request’packet and a ‘response’ packet which are matched based on methodspecified in the control table.” ::= { responseTime 3 }responseTimeDataEntry OBJECT-TYPE SYNTAX responseTimeDataEntry ACCESSnot-accessible STATUS mandatory DESCRIPTION “A conceptual row in theresponseTimeDataTable. An example of the indexing of this entry isresponseTimeData.7.5678” INDEX { responseTimeTimeMark,responseTimeControlIndex } ::= { responseTimeDataTable 1 }responseTimeDataEntry ::= SEQUENCE { responseTimeTimeMark TimeFilter,responseTimeDataIndex Integer32, responseTimeData ZeroBasedCounter32, }responseTimeTimeMark OBJECT-TYPE SYNTAX TimeFilter MAX-ACCESSnot-accessible STATUS current DESCRIPTION “A TimeFilter for this entry.See the TimeFilter textual convention to see how this works.” ::= {responseTimeDataEntry 1 } responseTimeDataIndex OBJECT-TYPE SYNTAXInteger32 MAX-ACCESS read-only STATUS current DESCRIPTION “Distinguishesthis entry from other data entries” ::= { responseTimeDataEntry 2 }responseTimeData OBJECT-TYPE SYNTAX ZeroBasedCounter32 MAX-ACCESSread-only STATUS current DESCRIPTION “The time in milli-second betweenthe matched ‘response’ and ‘request’ packet. Maximum response time islimited by 32-bit maximum, otherwise ‘request’ is considered lost.” ::={ responseTimeDataEntry 3 } -- responseTimeStatsTableresponseTimeStatsTable OBJECT-TYPE SYNTAX SEQUENCE OFResponseTimeStatsEntry ACCESS not-accessible STATUS current DESCRIPTION“A running entry for each responseTimeControlIndex is kept in this tableafter probe creates first entry in the responseTimeDataTable.” ::= {responseTime 4 } responseTimeStatsEntry OBJECT-TYPE SYNTAXResponseTimeStatsEntry ACCESS not-accessible STATUS mandatoryDESCRIPTION “A conceptual row in the responseTimeStatsTable. An exampleof the indexing of this entry is responseTimeStatsAverage.7” INDEX {responseTimeControlIndex } ::= { responseTimeStatsTable 1 }ResponseTimeStatsEntry ::= SEQUENCE { responseTimeStatsAverageInteger32, responseTimeStatsMedian Integer32, responseTimeStatsMaximumInteger32, responseTimeStatsMinimum Integer32,responseTimeStatsOverallMaximum Integer32 } responseTimeStatsAverageOBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS currentDESCRIPTION “The average time in milli-second for the entries created inthe responseTimeDataTable per responseTimeControlIndex for the pastduration of responseTimeControlInterval.” ::= { responseTimeStatsEntry 1} responseTimeStatsMedian OBJECT-TYPE SYNTAX Integer32 MAX-ACCESSread-only STATUS current DESCRIPTION “The average time in milli-secondfor the entries created in the responseTimeDataTable perresponseTimeControlIndex for the past duration ofresponseTimeControlInterval.” ::= { responseTimeStatsEntry 2 }responseTimeStatsMaximum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESSread-only STATUS current DESCRIPTION “The maximum time in milli-secondfor the entries created in the responseTimeDataTable perresponseTimeControlIndex for the past duration ofresponseTimeControlInterval.” ::= { responseTimeStatsEntry 3 }responseTimeStatsMinimum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESSread-only STATUS current DESCRIPTION “The average time in milli-secondfor the entries created in the responseTimeDataTable perresponseTimeControlIndex for the past duration ofresponseTimeControlInterval.” ::= { responseTimeStatsEntry 4 }responseTimeStatsOverallMaximum OBJECT-TYPE SYNTAX Integer32 MAX-ACCESSread-only STATUS current DESCRIPTION “The maximum time in milli-secondfor the entries created in the responseTimeDataTable perresponseTimeControlIndex for the duration of response time sampling.”::= { responseTimeStatsEntry 5 } END

In summary, the present invention determines performance statisticsassociated with the request and response data packets sent and receivedby the client and server computer systems. The present invention usesfilters to identify and select request and response data packets thatwill be used to generate performance statistics. The present inventionapplies time-stamps to the request and response data packets. Thepresent invention uses correlation rules to correlate a response packetto a request packet, so that the time-stamps can be used to determinetime intervals associated with the time between transmission andreception of the data packets by the computer systems. The presentinvention uses the time intervals to determine the performancestatistics. In one embodiment, the present invention implements theabove method in an extension to an RMON MIB.

In the manner described above, the present invention computesperformance statistics for application. response time, applicationprocessing time, and network latency, and reports the performancestatistics to the network manager at a prescribed interval. The presentinvention thus provides a method for monitoring a computer systemcommunication network that readily and quickly detects and identifiesdegradation of the network. The present invention described hereinmeasures performance time at the end-user computer systems and thusprovides an accurate measure of the performance and reliability of thenetwork. The performance statistics generated by the present inventioncan be used to measure the performance of the network against theprovisions of a governing service level agreement. The present inventionis implemented through the client and server computer systems, and thusis also cost-effective. The use of an RMON MIB extension means thepresent invention is compatible with the SNMP protocol currentlyemployed in computer system communication networks.

The preferred embodiment of the present invention, application responsetime and network latency monitoring using RMON/RMON2-based extensions,is thus described. While the present invention has been described inparticular embodiments, it should be appreciated that the presentinvention should not be construed as limited by such embodiments, butrather construed according to the following claims.

What is claimed is:
 1. In a communication network comprising computersystems communicatively coupled to each other with communicationequipment, a method for quantifying communication performance comprisingthe steps of: a) a client computer system measuring performancestatistics associated with data packets sent and received by saidcomputer systems, said step a) comprising the steps of: a1) applying afirst time-stamp to data packets sent by a computer system over saidcommunication equipment and applying a second time-stamp to data packetsreceived by a computer system over said communication equipment; a2)correlating a first data packet sent by a first computer system oversaid communication network to a second data packet sent by a secondcomputer system over said communication network; a3) computing adifference between said first time-stamp and said second time-stamp; anda4) calculating performance statistics measured on said difference andstoring said performance statistics in a memory unit within said firstcomputer system; and b) said client computer system reporting saidstored performance statistics to a central computer system.
 2. Themethod as recited in claim 1 wherein said step a) is implemented using amanagement information base extension to Remote Network Monitoring(RMON)-based computer software, said management information baseextension comprising a response time control table, a response timecorrelation table, a response time data table, and a response timestatistics database.
 3. The method as recited in claim 1 wherein stepa1) further comprises applying said first time-stamp and said secondtime-stamp at a network interface card of said client computer system.4. The method as recited in claim 1 wherein step a1) further comprisesapplying said first time-stamp and said second time-stamp at a protocolstack of said client computer system.
 5. The method as recited in claim1 wherein said performance statistics measure application response timeand wherein step a1) further comprises the steps of: applying said firsttime-stamp to said first data packet when said first data packet is sentby said first computer system to said second computer system; andapplying said second time-stamp to said second data packet when saidsecond data packet is received by said first computer system from saidsecond computer system, wherein said second data packet is anacknowledgment and sent in response to said first data packet, saidfirst computer system being said client computer system and said secondcomputer system being a server computer system.
 6. The method as recitedin claim 1 wherein said performance statistics measure applicationprocessing time and wherein step a1) further comprises the steps of:applying said first time-stamp to said first data packet when said firstdata packet is received by said second computer system from said firstcomputer system; and applying said second time-stamp to said second datapacket when said second data packet is sent by said second computersystem, wherein said second data packet is an acknowledgment and sent inresponse to said first data packet, said first computer system beingsaid client computer system and said second computer being a servercomputer system.
 7. The method as recited in claim 1 wherein saidperformance statistics measure network latency and wherein step a1)further comprises the steps of: applying said first time-stamp to saidfirst data packet when said first data packet is sent by said firstcomputer system to said second computer system; and applying said secondtime-stamp to said first data packet when said first data packet isreceived by said second computer system, wherein said first computersystem is said client computer system and said second computer system isa server computer system.
 8. The method as recited in claim 1 whereinstep a2) further comprises the steps of: comparing said first datapacket and said second data packet to correlation rules, saidcorrelation rules defining matching characteristics for comparing saiddata packets; and pairing said first data packet and said second datapacket when said correlation rules are satisfied.
 9. The method asrecited in claim 8 further comprising applying a filter for recognizingsaid data packets sent by and received by said computer systems, whereinsaid filter is comprised of recognition characteristics.
 10. The methodas recited in claim 8 wherein said correlation rules comprise matchingof source and destination addresses of said first and second datapackets.
 11. In a communication network comprising computer systemscommunicatively coupled to each other with communication equipment, amethod for quantifying communication performance comprising the stepsof: a) a server computer system measuring performance statisticsassociated with data packets sent and received by said computer systems,said step a) comprising the steps of: a1) applying a first time-stamp todata packets sent by a computer system over said communication equipmentand applying a second time-stamp to data packets received by saidcomputer system over said communication equipment; a2) correlating afirst data packet sent by a first computer system over saidcommunication network to a second data packet sent by a second computersystem over said communication network; a3) computing a differencebetween said first time-stamp and said second time-stamp; and a4)calculating performance statistics measured on said difference andstoring said performance statistics in a memory unit within said servercomputer system; and b) said server computer system reporting saidstored performance statistics to a central computer system.
 12. Themethod as recited in claim 11 wherein said step a) is implemented usinga management information base extension to Remote Network Monitoring(RMON)-based computer software, said management information baseextension comprising a response time control table, a response timecorrelation table, a response time data table, and a response timestatistics database.
 13. The method as recited in claim 11 wherein stepa1) further comprises applying said first time-stamp and said secondtime-stamp at a network interface card of said server computer system.14. The method as recited in claim 11 wherein step a1) further comprisesapplying said first time-stamp and said second time-stamp at a protocolstack of said server computer system.
 15. The method as recited in claim11 wherein said performance statistics measure application response timeand wherein step a1) further comprises the steps of: applying said firsttime-stamp to said first data packet when said first data packet is sentby said first computer system to said second computer system; andapplying said second time-stamp to said second data packet when saidsecond data packet is received by said first computer system from saidsecond computer system, wherein said second data packet is anacknowledgment and sent in response to said first data packet, saidfirst computer system being a client computer system and said secondcomputer system being said server computer system.
 16. The method asrecited in claim 11 wherein said performance statistics measureapplication processing time and wherein step a1) further comprises thesteps of: applying said first time-stamp to said first data packet whensaid first data packet is received by said second computer system fromsaid first computer system; and applying said second time-stamp to saidsecond data packet when said second data packet is sent by said secondcomputer system, wherein said second data packet is an acknowledgmentand sent in response to said first data packet, said first computersystem being a client computer system and said second computer beingsaid server computer system.
 17. The method as recited in claim 11wherein said performance statistics measure network latency and whereinstep a1) further comprises the steps of: applying said first time-stampto said first data packet when said first data packet is sent by saidfirst computer system to said second computer system; and applying saidsecond time-stamp to said first data packet when said first data packetis received by said second computer system, wherein said first computersystem is said server computer system and said second computer system isa client computer system.
 18. The method as recited in claim 11 whereinstep a2) further comprises the steps of: comparing said first datapacket and said second data packet to correlation rules, saidcorrelation rules defining matching characteristics for comparing saiddata packets; and pairing said first data packet and said second datapacket when said correlation rules are satisfied.
 19. The method asrecited in claim 18 further comprising applying a filter for recognizingsaid data packets sent by and received by said computer systems, whereinsaid filter is comprised of recognition characteristics.
 20. The methodas recited in claim 18 wherein said correlation rules comprise matchingof source and destination addresses of said first and second datapackets.
 21. A computer system comprising: a processor coupled to a bus;and a memory unit coupled to said bus and having stored thereininstructions that when executed by said processor implement a method forquantifying communication performance of a communication networkcomprising computer systems communicatively coupled to each other, saidmethod comprising the steps of: a) measuring performance statisticsassociated with data packets sent and received by said computer systems,said step a) comprising the steps of: a1) time-stamping data packetssent by a computer system over said communication equipment andtime-stamping data packets received by said computer system over saidcommunication equipment; a2) correlating a first data packet sent by afirst computer system on said communication network to a second datapacket sent by a second computer system on said communication network;a3) computing a difference between a first time-stamp of said first datapacket and a second time-stamp of said second data packet; and a4)calculating performance statistics measured on said difference andstoring said performance statistics in a memory unit within said firstcomputer system; and b) said first computer system reporting said storedperformance statistics to a central computer system.